Sumo Logic で DNSクエリログをセキュリティ分析する

ログ分析の中でDNSクエリログはセキュリティを強化する上で非常に重要なログです。ログをSIEMに保管してどう活用すべきか、高度な分析を行うためのポイントをご紹介します。

#Sumo Logic

酒井剛

2023.10.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

DNS はシステムがネットワーク通信を行う上で必須の技術になっていて、通信のかなり初期段階で発生します。
ほぼすべての通信で発生するため、DNSクエリログはセキュリティのためのログ分析を行う上で収集する対象となるかと思います。

今回は DNSクエリログをSIEMプラットフォームである Sumo Logic に収集して分析したいと思います。

セキュリティを高めるために色んな観点で分析することができますが、よく見るところとしてどんなところに注目すべきかご紹介したいと思います。
今回はAWSのDNSサービスである Route53 Resolver のログについて見ていきます。
また、コーポレート内のDNSログを分析したい場合でも Route53 Resolver のログの分析観点と大差はありませんので、読み替えていただくことができます。

Sumo Logic App を活用する

Amazon Route53 のログ分析には Sumo Logic のプリビルドのダッシュボード（App）を使って分析していくことができます。

App のインストール方法は下記でも紹介している通り、取り込んだログの場所を設定するだけでわずか数クリックでダッシュボードを作成することができます。

App Catalog の設定から「Amazon Route 53 Resolver Security」を探して App をインストールしましょう。

この App は Route53 Resolver のクエリログおよび DNS Firewall ログを対象に可視化・分析することができます。

Route53 Resolver クエリログ

Route53 Resolver のクエリログは一般的な BIND等のクエリログと同じ分析観点になります。

「Amazon Route 53 Resolver Security - Security Details」のダッシュボード

クエリログを分析するために、まず「Amazon Route 53 Resolver Security - Security Details」のダッシュボードを使います。

VPC ID と DNSクエリタイプ（Aレコード、AAAAレコード、TXTレコード、MXレコードなど）ごとにリクエストの数を統計化しています。またその隣のパネルでは、DNSリクエストのバイト数の統計情報を出しています。

DNSリクエストのバイト数では、C2サーバーとのDNS通信が悪用された場合の不審な長い文字数のDNSクエリが発生していないか可視化することができます。
こちらのセキュリティレポートの例では異常に長い文字数のDNSクエリがどのように悪用されるか説明されていますので、見るポイントのイメージとして参考にしてみてください。

同じようにインスタンスID・送信元IPを軸にDNSクエリタイプごとのリクエスト統計も確認できるので、対象の軸を変えて分析ができます。

次はクエリごとのテーブル表示になります。どんなクエリが発生しているかを確認することができるので注目に値するクエリが発生していないか見ることができます。

Top 50 Highest Entropy Domains のパネルではランダム性の高いドメインへのクエリが発生していないかを分析することができます。
セキュリティ製品は悪性なドメインをいち早く特定し、そのドメインへの通信を防御しようとしますが、攻撃者はさらにその防御をかいくぐるために素早くドメインを切り替えます。
ドメインは世界でユニークな文字列を利用する必要があるので、攻撃者はDGA（Domain Generation Algorithm）というドメイン生成アルゴリズムを使って、ドメインの生成を自動化します。そういったランダム性の高いドメインへのクエリが発生していないかを分析することができます。

Top 50 Domains by Query Length and InstanceID のパネルは先程の観点と同じで、エンコードされた情報を含むような異常に長い文字数や意味不明の英数字の羅列のDNSクエリがないか確認します。

Reverse DNS Query to Non-Existent Domain by ... のパネルでは存在しない逆引き（IPアドレスからドメインを検索する）を行ったインスタンスがいないか分析します。逆引きの用途（参考文献）として、メールサーバーのように、サーバー側で逆引きできないとメールの配送を受け付けない設定をしていて使われる場合がありますが、ネットワーク探索などでも利用される可能性があるため、これらのパネルを使って不審な通信がないかを確認します。

Successful Reverse DNS Query by ... のパネルでは存在するドメインへの逆引きクエリについて分析します。
逆引きを行うべきインスタンスなのか、頻度などを分析して、ネットワーク探索などの攻撃者による行動がなかったか分析していきます。

また、ダッシュボードの最上部に戻ると、これらのパネルをフィルタを使って、効果的に見たいものに絞っていくことが可能です。
特にSIEMで行われる相関分析では、他のシステムのログから見える情報を関連付けしていくことが重要になってきます。
例えばプロキシログで不審なURLへのアクセスログを見つけていた場合は、DNSクエリログで特定の query name のフィルタを使って絞り込み検索をすることができます。
インスタンスが特定できている場合は、instance id のフィルタで絞ってこれまで紹介したセキュリティインサイトを得る観点で相関づけします。

「Amazon Route 53 Resolver Security - Threat Intel」のダッシュボード

「Amazon Route 53 Resolver Security - Threat Intel」のダッシュボードでは CrowdStrike の脅威インテリジェンスとDNSクエリログを突合して、ドメイン・IPアドレスが過去に攻撃者に使われたものがなかったか調べることができます。

脅威判定されたドメインのクエリを行った回数です。
脅威の信頼性とCrowdStrikeが識別している攻撃者グループが表示されます。

脅威判定されたDNSクエリを行ったインスタンス、時系列での統計を分析することができます。

テーブル形式で詳細を確認することができます。

DNSクエリに含まれるIPアドレスを基にCrowdStrikeの脅威インテリジェンスと突合した分析結果です。上記と同様の観点で分析することができます。

今回のご紹介例はデモ環境のため、多くの脅威が突合された結果が表示されていますが、本来の運用であれば、表示が一つでもあればすぐに確認ができるようにアラートを設定するのが良いです。

オンプレなどでBIND等のDNSクエリログを分析したい場合

執筆時点では、Sumo Logic でオンプレのDNSクエリログを対象にしたプリビルドのダッシュボード（App）はないようです。
今回ご紹介したApp「Amazon Route 53 Resolver Security」の分析観点をそのまま流用していただくことができると思いますので、こちらのダッシュボードのクエリをコピーしながらデータソースやパースを少し修正していくことで同様のダッシュボードをつくることができそうです。